Circuit designs (e.g., for computer hardware) are normally verified before being fabricated. During verification, a design is sometimes referred to as a design under test (DUT). Typically, a DUT is verified by running a simulation program on a computer during which different inputs (called stimuli, inputs, or events) are in turn applied to the DUT, and the signals at the outputs of the DUT are collected and compared with expected values of the design specification. When actual output values of the DUT do not agree with predicted values of the design specification, the circuit design is considered defective and is usually re-designed.
Often times, a particular input to a DUT yields a single, predictable output. For example, input A results in output X, while input B results in output Y. Conventional verification software often very straightforwardly compares a predicted output to the actual output of the DUT as the simulation time advances.
More specifically, a exemplary known environment for verifying a DUT includes the DUT, a stimulus generator, a behavioral model of the DUT, and an output checker. This type of simulation scheme is sometimes known as on-the-fly verification as the outputs of the DUT are checked as they are produced. In this technique, an ordered series of stimulus vectors (e.g., input vectors) is generated by the stimulus generator. The input vectors are fed one-by-one in order simultaneously to the DUT and the behavioral model. For each input vector, the DUT produces an ordered series of output vectors, and the behavioral model produces an ordered series of check vectors.
The function of the output checker is to compare each output vector (e.g., from the DUT) to a corresponding check vector (e.g., from the behavioral model). A first-in-first-out (FIFO) buffer may be used to queue the check vectors, since the behavioral model often generates its vectors faster than the DUT. Whenever the DUT produces an output vector, the next available check vector in the FIFO is dequeued from the FIFO and the two vectors are checked against each other. If the output vector does not equal the check vector, then a simulation error is immediately flagged.
The FIFO is used to compensate for the relative delays between the DUT and behavioral model. Often, the behavioral model is a functionally accurate version of the DUT but does not model any of the real-life delays which will be unavoidable in the real design. Thus when verifying a synchronous design, the behavioral model will typically produce a check vector for every clock cycle it is given a stimulus, and produce it within the same clock cycle. On the other hand, the DUT exhibits timing delays, e.g., due to the presence of latches. As a result, it is often only possible to produce the output vector at a later clock cycle from when a stimulus vector was first received. Thus the FIFO acts to compensate for the speed differential between the behavioral model and the DUT by storing check vectors in order until the corresponding output vector is produced.
The test environment described thus far works well when there is a one-to-one correspondence between the series of check vectors and output vectors (e.g., for each input vector produced by the stimulus generator and input to the DUT and BM, one output vector is produced by the DUT and one check vector is produced by the behavioral model). However, a given DUT often does not have sufficient bandwidth to process every stimulus vector it receives. So, for example, given three input vectors (e.g., Sn, Sn+1, Sn+2) the DUT may process sn to produce a first output vector. However, in some circumstances the DUT ignores the second input vector sn+1 due to lack of bandwidth because it is busy processing sn. Then, when the next stimulus vector sn+2 arrives at a sufficient later time, the DUT produces a second output vector.
Meanwhile the behavioral model produces first, second, and third check vectors from the same three input vectors (e.g., sn, sn+1, Sn+2), respectively, since the behavioral model does not exhibit the same delay as the DUT. Put another way, the behavioral model does not ignore the second input vector. Accordingly, in the on-the-fly test environment described above, the checker will compare the second output vector to the second check vector. However, the second output vector and the second check vector do not correspond to one another because they were produced from different input vectors. Particularly, the second output vector was produced from the third input vector, while the second check vector was produced from the second input vector. Thus, the values of the second output vector to the second check vector most likely will not be equal, and an error will be indicated when the checker compares these two vectors.
An alternative technique for verifying a DUT employs post processing. In this environment, the series of output vectors from the DUT is stored in a memory array. When all input vectors have been submitted to the DUT and processed, the contents of the array are checked to ensure the output behavior was as expected.
However, post-processing techniques can fail to identify anomalous behavior of the DUT. For example, if the function of the DUT is to write data to the memory array, the DUT could, during the simulation, write bad data to the array and then later overwrite that array location with correct data. When post checking of the memory array occurs, the test environment will not detect this anomalous behavior because good data is now in the array.
Moreover, in post-processing techniques, anomalous behavior will not be flagged as it occurs. When the DUT produces an bad (e.g., unexpected) output vector, that output vector is stored in the array and only detected later when post-checking of the array occurs. A simulation log is then examined to discover the exact moment when the bad output vector was produced. Depending upon the size of the log, this can require significant analysis time. With on-the-fly verification, on the other hand, output vectors are checked as soon as they emerge from the DUT, so the simulation can be stopped immediately and the error highlighted.
Another known solution is to generate a more accurate behavioral model of the DUT, e.g., one that models the delays of the real design. However, the person creating the test environment needs intimate knowledge of the DUT design in order to achieve this model. Often this person is not the same person as the actual designer of the DUT, and so this knowledge may not be so readily available. In addition, the model complexity would be greatly increased.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.